1. Field of the Invention
The present invention relates to the field of client-server computing, and more particularly to a method and system for managing client services interacting with multiple browser pages.
2. Brief Description of Prior Developments
There has recently been a tremendous growth in the number of computers connected to the Internet. A client computer connected to the Internet can download digital information from server computers. Client application software typically accepts commands from a user and obtains data and services by sending requests to server applications running on the server computers. A number of protocols are used to exchange commands and data between computers connected to the Internet. The protocols include the File Transfer Protocol (FTP), the Hyper Text Transfer Protocol (HTTP), the Simple Mail Transfer Protocol (SMTP), and the Gopher document protocol. The HTTP protocol is used to access data on the World Wide Web, often referred to as xe2x80x9cthe Web.xe2x80x9d The Web is an information service on the Internet providing documents and links between documents. It is made up of numerous Web sites located around the world that maintain and distribute electronic documents. A Web site may use one or more Web server computers that store and distribute documents in a number of formats, including the Hyper Text Markup Language (HTML). An HTML document includes text and metadata (commands providing formatting information), as well as embedded links that reference other data or documents. The referenced documents may represent text, graphics, or video. In addition, HTML documents may contain client scripts (e.g. Java Script or Visual Basic Script) that are executed on the browser. The browser executes these scripts in a scripting space. A script is a set of instructions that are executed at certain times, e.g. when a Web page is loading, when a Web page is done loading, when the user has clicked on a link, when an event has occurred, etc.
An intranet is a local area network containing Web servers and client computers operating in a manner similar to the World Wide Web described above. Typically, all of the computers on an intranet are contained within a company or organization.
A client computer connected to a network, such as a local area network, wide area network, an intranet, or the Internet, can download digital information from server computers. This digital information can be presented to a user with and executed by a Web browser.
A Web browser is a client application or, preferably, an integrated operating system utility that communicates with server computers via FTP, HTTP and Gopher protocols. Web browsers receive content from a server sent over the Internet that is typically encoded in Hyper Text Markup Language (HTML) and executed by the browser on a client computer. Such HTML documents may include scripts (e.g. Java Scripts or Visual Basic Scripts) that allow for some basic flexibility. To go beyond what is possible with HTML and embedded scripts, browsers typically support the usage of additional components such as Java Applets, ActiveX Controls and Plug-Ins that provide extra functionality. These additional components, referred to as xe2x80x9cclient bits,xe2x80x9d are typically stored as executables in the memory of the client computer, and can be installed onto the client computer directly from a storage medium or downloaded from a server over the Internet. The functional components such as Java Applets, ActiveX Controls and Plug-Ins are mapped as objects into the script so that actions, methods or properties of an object can be called therefrom. (ActiveX Controls are reusable software components that incorporate ActiveX technology, which enables software applications to interact with one another in a networked environment regardless of the language in which the components were created. ActiveX Controls can be embedded in Web pages to produce animation and other multimedia effects, interactive objects and sophisticated applications. ActiveX Controls can be written in a variety of programming languages, including C, C++, Visual Basic and Java. A Plug-In, on the other hand, is a software component designed to plug into the Netscape Navigator browser, and to permit the browser to access and execute files embedded in HTML documents that are in formats the browser normally would not recognize.) Objects in this context are, e.g., dual-interface COM objects, which can communicate bi-directionally. From script, methods can be called, properties can be accessed and properties can be set. From the object, events can be sent to the browser scripting space to an event handler.
Also, Web browsers have an associated scripting space, which is memory space allocated for a browser instance, for the reception of electronic data called a script. Web browsers typically receive scripts as part of HTML documents from the network and execute them in their scripting space and execute instructions contained in the script. HTML content is typically information that is displayed to the user, and the scripting space can contribute to such content. Such content can be presented to a user, usually by way of an output device such as a computer monitor. In addition, the script may contain mappings to objects such as Active X Controls, Java Applets, Plug-Ins, etc. stored in the memory of a client computer and instructions for interaction with or communication to and from those objects. A script might contain additional instructions that allow an exchange between script instructions in a scripting space and objects that are mapped into the scripting space. In these cases, a mapping to the Plug-In object or ActiveX control object is contained in the script, and the Plug-In or ActiveX control performs some operation towards carrying out the script instruction.
For example, in a typical Web scenario, a Web browser receives an HTML document with an embedded script or scripts, wherein an embedded script uses an object to carry out additional functionality that can not be performed with HTML and the embedded script alone. The browser starts executing the script and maps the object into its scripting space. After that, the script can call methods of, read properties of or write properties to the object mapped into the scripting space. Currently, when the script is loaded and executed in the scripting space, instructions for an object are preceded by creating the object in the memory of the client computer. After that, the exchange of information (in the form of the script calling methods or accessing properties of the object, or in form of the object sending events to the scripting space) between the scripting space and the object is possible. When a user navigates to a new Web page, however, the object is disconnected from the scripting space and destroyed, and any state that was acquired during the lifetime of the object is lost. In addition, the scripting space itself is initialized again to get ready for the next request.
A problem thus arises when subsequent or additional scripting spaces try using the object, because the object has been destroyed and needs to be re-created. The problem is compounded when the object needs to accumulate some state before it is operational e.g., when connection to a server is required, when initialization procedures consume too much time, power or bandwidth, when user authentication via password is required, etc. A common scenario in which these problem(s) are evident occurs when a user navigates away from a Web page that uses an object as described above, and after a short time returns to that same Web page. With prior browser infrastructure, the object is re-created, and re-initialized with any state that is required for its execution, as described above. The same is true when a user creates a second or additional browser instance for the display of the same Web page address. The second or additional browser instance has a different scripting space that receives the same script. The second or additional browser instance could be in an entirely different browser application (different brand browser) or in a different instance of the same browser application. In either case, it is desirable for the script of the additional browser instance to map the exact same object that is used by the other browser instance into its scripting space, since initialization is costly. Alternatively, if a link to another Web page is input by the user via a computer input device, another Web page is displayed with a different script that may have instructions pertaining to the previously used object. Once again, the object needs to be re-created the first time it is encountered in the new script because it was previously destroyed and the browser has no notion or memory of any previously or currently existing instances of the object. It would thus be advantageous to provide a framework or infrastructure that overcomes these problems, and wherein the framework allows multiple scripting spaces of multiple browser instances to have access to and communication with objects, and wherein objects can retain state across multiple browser instances.
Stated differently, a problem with existing browser infrastructure is that every time a new scripting space receives a script with a mapping to objects that were created previously, these objects have to be created anew for the new scripting space. This can constitute inefficient use of computing resources, particularly for objects that undergo frequent or multiple information exchange with browser scripting spaces, or for objects that have expensive initialization steps associated therewith, as described above. In addition, the user experience may suffer if an initialization step requires user input, e.g., supplying passwords, etc. Thus, it would be advantageous to provide an infrastructure whereby such objects persist across Web pages, thus avoiding destruction and re-creation of objects.
At the core of an infrastructure that could achieve these advantages would be a service manager that can create and maintain communication with objects so that information relating to these objects can persist across different browser Web pages. These objects are called xe2x80x9cservicesxe2x80x9d in connection with the service manager since, in contrast to current browser infrastructure, objects of a service manager infrastructure are browser independent and are not mapped directly into the browser""s scripting space. Since the services are browser independent and they exist in relation to the service manager, the services would be capable of being used by any application that can interface with the service manager.
A service manager for managing services and objects called by browser scripts is employed. The Web browser script is not in direct communication with the service manager; instead, a connector object is mapped by the script into the scripting space. For function calls that the script would previously make to the service or object directly, the script makes a call to a connector object. Depending on the browser brand, the connector object is of a different format e.g., an ActiveX control or a Plug-In. The first time such a connector object is created and mapped into a scripting space, the service manager is initiated and all of the services and objects that are managed by the service manager are loaded. The connector object packages the function call to a service for interpretation by the service manager. A script wrapper is a small object between the scripting space and the connector object, and allows script to be written without regard to different browser brands. The service manager, when receiving a packaged service call from a connector object, forwards the service call to the corresponding service or object within its control. The service then performs according to the call and information can flow back to the script via the service manager and connector object e.g., an ActiveX control interface or Plug-In interface. Services managed by the service manager can also send information regarding events to the scripting space by way of the service manager, the connector object, and the script wrapper. An event handler can be implemented by the script author if the event is of interest to the script. As a result, the destruction and re-creation of objects that typically occurs when objects are mapped directly into the scripting space are avoided. All that is destroyed and re-created are the communication channels (namely the connector object and the script wrapper) between the scripting space and the services that are managed by the service manager. This allows any state within the service to persist across different Web pages, thereby improving users"" browsing experience. Other features of the present invention are described below.